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Abstract 
This document specifies extensions to Resource Reservation Protocol - 
Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and 
Loopback (LB) mechanisms for Label Switched Paths (LSPs). These 
mechanisms are applicable to technologies that use Generalized MPLS 
(GMPLS) for the control plane. 
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Authors’ Addresses 
1. Introduction 


The requirements for Lock Instruct (LI) and Loopback (LB) in the 
Multiprotocol Label Switching Transport Profile (MPLS-TP) are 
specified in [RFC5860], and the framework of LI and LB is specified 
in [RFC6371]. A Label Switched Path (LSP) that is locked, using LI, 
is prevented from carrying user data traffic. The LB function can 
only be applied to an LSP that has been previously locked. 


In general, the LI and LB are useful Operations, Administration, and 
Maintenance (OAM) functions for technologies that use Generalized 
MPLS (GMPLS) for the control plane, e.g., time-division multiplexing, 
wavelength-division multiplexing, and packet switching. It is 
natural to use and extend the GMPLS control-plane protocol to provide 
a unified approach for LI and LB provisioning in all these 
technologies. 


[RFC7487] specifies the RSVP-TE extensions for the configuration of 
proactive MPLS-TP OAM functions, such as Continuity Check (CC), 
Connectivity Verification (CV), Delay Measurement (DM), and Loss 
Measurement (LM). The provisioning of on-demand OAM functions such 
as LI and LB are not covered in that document. 


This document specifies extensions to Resource Reservation Protocol- 


Traffic Engineering (RSVP-TE) to support lock instruct and loopback 
mechanisms for LSPs. The mechanisms are applicable to technologies 
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that use GMPLS for the control plane. For a network supporting MPLS- 
TP, the mechanisms defined in this document are complementary to 
[RFC6435]. 

1.1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 

2. Flag Definitions for LI and LB 

2.1. Lock Instruct Indication 
In order to indicate the lock/unlock status of the LSP, the A 
(Administratively down) bit in the Administrative Status 
(ADMIN_STATUS) Object [RFC3471] [RFC3473] is used. 


2.2. Extensions for Loopback 


In order to indicate the loopback mode of LSP, a new bit flag is 
defined in the Attribute Flags TLV [RFC5420]. 


Loopback flag: 
This flag indicates a particular node on the LSP is required to 


enter loopback mode. This can also be used for specifying the 
loopback state of the node. 


Bit number: 13 


Attribute flag carried in Path message: Yes 


Attribute flag carried in Resv message: No 


- Attribute flag carried in the Record Route Object (RRO) 
Attributes subobject: Yes 


3. Operational Procedures 

3.1. Lock Instruct 
When an ingress node intends to put an LSP into lock mode, it MUST 
send a Path message with the Administratively down (A) bit used as 


specified above and the Reflect (R) bit in the ADMIN_STATUS Object 
set. 
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On receipt of this Path message, the egress node SHOULD try to take 
the LSP out of service. If the egress node locks the LSP 
successfully, it MUST send a Resv message with the A bit in the 
ADMIN_STATUS Object set. Otherwise, it MUST send a PathErr message 
with the Error Code "OAM Problem" [RFC7260] and the new Error Value 
"Lock Failure", and the following Resv messages MUST be sent with the 
A bit cleared. 


When an LSP is put in lock mode, the subsequent Path and Resv 
messages MUST keep the A bit in the ADMIN_STATUS Object set. 


When the ingress node intends to take the LSP out of the lock mode, 
it MUST send a Path message with the A bit in the ADMIN_STATUS Object 
cleared. 


On receipt of this Path message, the egress node SHOULD try to bring 
the LSP back to service. If the egress node unlocks the LSP 
successfully, it MUST send a Resv message with the A bit in the 
ADMIN_STATUS Object cleared. Otherwise, it MUST send a PathErr 
message with the Error Code "OAM Problem" [RFC7260] and the new Error 
Value "Unlock Failure", and the following Resv messages MUST be sent 
with the A bit set. 


When an LSP is taken out of lock mode, the subsequent Path and Resv 
messages MUST keep the A bit in the ADMIN_STATUS Object cleared. 


3.2. Loopback 


The loopback request can be sent either to the egress node or to a 
particular intermediate node. The mechanism defined in [RFC7570] is 
used for addressing the loopback request to a particular node on the 
LSP. The ingress node MUST ensure that the LSP is in lock mode 
before it requests setting a particular node on the LSP into loopback 
mode. 


When an ingress node intends to put a particular node on the LSP into 
loopback mode, it MUST send a Path message with the Loopback 
Attribute Flag defined above in the Attribute Flags TLV set. The 
mechanism defined in [RFC7570] is used to address the loopback 
request to the particular node. The ingress node MUST ensure that 
the entity at which loopback is intended to occur is explicitly 
identified by the immediately preceding subobject of the Explicit 
Route Object (ERO) Hop Attributes subobject. The Administratively 
down (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate 
that the LSP is still in lock mode. 
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On receipt of this Path message, the target node of the loopback 
request MUST check if the LSP is in lock mode by verifying that the 
Administratively down (A) bit is set in the ADMIN_STATUS Object. If 
the bit is not set, the loopback request MUST be ignored. If the bit 
is set, the node MUST check that the desired loopback entity is 
explicitly identified by the ERO subobject prior to the ERO Hop 
Attributes subobject. Currently, the type value MUST be verified to 
be less than 32 (i.e., able to identify a specific entity where a 
loopback can occur; see Section 4.3), and for type values 1 (IPv4 
prefix) and 2 (IPv6 prefix), the prefix length MUST be 32 and 128, 
respectively. If the desired loopback entity is not explicitly 
identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE 
object" error SHOULD be generated. Otherwise, the node SHOULD try to 
put the LSP into loopback mode. The loopback SHOULD be enabled on 
the entity identified by the ERO subobject immediately prior to the 
ERO Hop Attributes subobject. If the immediately preceding subobject 
is a label subobject [RFC3473], the loopback SHOULD be enabled for 
the direction indicated by the U bit of the label subobject. 


If the node puts the LSP into loopback mode successfully, it MUST set 
the Loopback Attribute Flag if it adds, per [RFC7570], an RRO Hop 
Attributes subobject to the RRO of a Path or Resv message. The 
Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept 
set in the message. If the node cannot put the LSP into loopback 
mode, it MUST send a PathErr message with the Error Code "OAM 
Problem" [RFC7260] and the new Error Value "Loopback Failure". 


When the ingress node intends to take the particular node out of 
loopback mode, it MUST send a Path message with the Loopback 
Attribute Flag in the Attribute Flags TLV cleared. The mechanism 
defined in [RFC7570] is used to indicate that the particular node 
SHOULD exit loopback mode for this LSP. The Administratively down 
(A) bit in the ADMIN_STATUS Object MUST be kept set to indicate the 
LSP is still in lock mode. 


On receipt of this Path message, the target node SHOULD try to take 
the LSP out of loopback mode. If the node takes the LSP out of 
loopback mode successfully, it MUST clear the Loopback Attribute Flag 
in the RRO Hop Attributes subobject and push this subobject onto the 
RRO object in the corresponding Path or Resv message. The 
Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept 
set in the message. Otherwise, the node MUST send a PathErr message 
with the Error Code "OAM Problem" [RFC7260] and the new Error Value 
"Exit Loopback Failure". 


After the loopback mode is cleared successfully, the ingress node MAY 
remove the Lock Instruct using the mechanism defined in Section 3.1. 
The ingress node MUST NOT request to exit lock mode if the LSP is 
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still in loopback mode. The egress node MUST ignore such a request 
when the LSP is still in loopback mode. 

4. IANA Considerations 


IANA has assigned new values defined in this document and summarized 
in this section. 


4.1. Attribute Flags 
IANA maintains a registry called "Resource Reservation Protocol- 
Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called 


"Attribute Flags". 


IANA has assigned a new bit flag as follows: 


Bit | | Attribute | Attribute | | | 

No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference 

TAE seat nS 
13 | Loopback | Yes | No | Yes Yes |this document 


4.2. RSVP Error Value Sub-Codes 


IANA maintains a registry called "Resource Reservation Protocol 
(RSVP) Parameters" with a sub-registry called "Error Codes and 
Globally-Defined Error Value Sub-Codes". 


IANA has assigned four new Error Value sub-codes for the "OAM 
Problem" Error Code: 


Value | Description | Reference 
== 4+-----------— - - - - YH Oe 
26 | Lock Failure | this document 
27 Unlock Failure this document 
28 Loopback Failure this document 
29 | Exit Loopback Failure | this document 


4.3. Allocation Rule for ERO Subobjects 
IANA maintains a registry called "Resource Reservation Protocol 
(RSVP) Parameters" with a sub-registry called "Class Names, Class 


Numbers, and Class Types". 


For Explicit Route Object, the allocation rule for subobject types in 
the range 5-31 (0x05 - Ox1F) has been updated as: 


5731 Unassigned (For explicit resource identification) 
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3% 


6. 


6. 


Security Considerations 


This document does not introduce any new security issues beyond those 
identified in [RFC3209], [RFC3473], and [RFC7570]. For amore 
comprehensive discussion of GMPLS security and attack mitigation 
techniques, please see "Security Framework for MPLS and GMPLS 
Networks" [RFC5920]. 


In addition, the reporting of the loopback status using the RRO may 
reveal details about the node that the operator wishes to remain 
confidential. The privacy considerations as described in paragraph 3 
of Section 5 of [RFC7570] also apply to this document. 
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